Power CD

home *** CD-ROM | disk | FTP | other *** search

/ Power CD / Power CD ATARI-Rechner Lieben.iso / UTILITY / WINX21 / WINX21.GER < prev next >

Wrap

Text File | 1993-09-09 | 24.6 KB | 456 lines

PROGRAMM WINX 2.1 [9.9.1993] - Patchprogramm für die GEM-Fensterverwaltung BESCHREIBUNG WINX erweitert das GEM der TOS Versionen bis 4.04 um einige Eigen- schaften, die auch unter MultiTOS zur Verfügung stehen. Aus der Sicht des Anwenders gehören dazu z.B. mehr Fenster, Kontroll- elemente an den hinteren Fenstern und eine erweiterte Benutzer- schnittstelle (betrifft die Bedienung der Kontrollelemente). Außerdem werden einige Fehler und Unzulänglichkeiten in den ver- schiedenen GEM Versionen behoben, wodurch die Benutzung des GEM wesentlich sicherer wird. Für den Entwickler ist zusätzlich die Möglichkeit interessant sich fehlerhafte Aufrufe der Fenster- funktionen anzeigen zu lassen. Theoretisch sollten alle 'sauberen' GEM-Programme mit fast allen Änderungen der Fensterverwaltung zurechtkommen, die Praxis sieht allerdings anders aus. So mußte z.B. auch das GEM-Desktop in einigen Punkten überarbeitet werden. Denken Sie daran, wenn eines ihrer Programme unter WINX fehlerhaft arbeitet, wird dies mit ziemlicher Sicherheit auch unter MultiTOS der Fall sein. Fordern Sie die Autoren auf ihre Programme anzupassen. Die erweiterte Benutzerschnittstelle integriert WINX ab TOS 2.xx ins GEM. Von nun an haben beide Maustasten beim Klick auf ein Kontrollelement des Fensterrahmens eine Funktion. Mit der rechten Taste kann man Aktionen auslösen, die erst beim Loslassen der Maustaste ausgeführt werden. Benutzt man die linke Taste, werden die Aktionen sofort und solange ausgeführt, wie man die Taste gedrückt hält. Erkennen kann man diesen Zustand daran, daß der Pfeil, der die Mausposition auf dem Bildschirm darstellt, seinen 'Schaft' verliert. Am Beispiel des Verschiebens eines Fensters soll dies deutlich werden. Nimmt man das Fenster am Bewegungs- element mit der rechten Taste auf, dann wird zunächst nur ein Rahmen gezeichnet, den man über den Bildschirm bewegen kann. Erst beim Loslassen wird das Fenster an der neuen Position dargestellt. Nimmt man hingegen die linke Taste, dann wird noch während des Bewegens die Fensterposition aktualisiert. Entsprechendes gilt für die Änderung der Fenstergröße, das Bewegen der Scrollbalken und das Benutzen von Schließ- und Maximalgröße-Element. Die Aktionen, die beim Klick mit der linken Maustaste auf die Scrollpfeile bzw. in die Scrollbereiche ausgelöst werden, haben sich nicht verändert. Sie führten ja auch bisher schon zu direkten Reaktionen des Anwendungsprogramms. Zusätzlich kann man durch einen Klick mit der rechten Maustaste auf die Scrollpfeile den Scrollbalken an den Anfang bzw. das Ende seines Scrollbereichs setzen. Klickt man in einen Scrollbereich, dann wird der Scroll- balken direkt auf die entsprechende Position gesetzt. Neue Kontrollelemente auf dem Fensterrahmen sind die Scrollboxen. Sie befinden sich am Ende jedes Scrollpfeils und ermöglichen das Scrollen mit Richtungswechsel und variabler Geschwindigkeit (falls Programme dies unterstützen). Nach dem Klicken auf eine Scrollbox (bzw. den zugehörigen Scrollpfeil) bestimmt die Aus- lenkung und die Entfernung des Mauspfeils von der Scrollbox die Scrollrichtung und -geschwindigkeit. Befindet sich der Maus- pfeil direkt über der Scrollbox wird nicht gescrollt. Solange die Maustaste gedrückt ist, kann man durch Verschieben der Maus die Scrollrichtung und -geschwindigkeit ändern. Eine weitere neue Möglichkeit hat man beim Klick auf den Fenster- titel. Konnte man damit bisher nur hintere Fenster nach vorne holen, ist es jetzt auch möglich das vorderste Fenster nach hinten zu stellen, falls das Programm bereits die entsprechende Meldung versteht. Die CONTROL-Taste dient als Modifizierer von Aktionen, die man durch einen Klick auf ein Kontrollelement des Fensterrahmens auslöst. Ist die CONTROL-Taste in dem Augenblick gedrückt in dem man mit der Maus klickt, dann wird die normale Bedeutung der Kontrollelemente ignoriert. Stattdessen wird das Fenster entweder nach vorne geholt bzw. nach hinten gestellt. Praktisch ist dies, wenn ein Fenster nur teilweise sichtbar ist. Ist die CONTROL-Taste gedrückt, während man die rechte Maustaste losläßt, dann wird die anstehende Aktion ignoriert (z.B. wenn man das Verschieben eines Fensters eingeleitet hat und es dann doch lieber an der alten Position hätte). Im folgenden sind die Änderungen, die WINX am GEM vornimmt, im einzelnen beschrieben, dabei steht '*' für 'neu in dieser Version' und '[G..]' bzw. '[L..]' für 'diese Änderung kann abgeschaltet werden' (-> KONFIGURATION). Leider ist dieser Teil teilweise sehr technisch. Trotzdem sollte man ihn sich mindestens einmal durch- lesen, da einem sonst einige Möglichkeiten verborgen bleiben. GEM-SCRENMGR: (Teil des GEM, der Klicks auf den Fensterrahmen verarbeitet) - [L1] Bedienung von Kontrollelementen an hinteren Fenstern * [G10] BackDrop-Erweiterung: Beim Klick auf die Titelzeile des vordersten Fensters wird es nach hinten gestellt (deaktiviert), falls die Applikation, der das Fenster gehört, diese neue Fähigkeit bereits unterstützt bzw. nur ein Fenster offen hat. * [G9] Hält man die CONTROL-Taste beim Klick auf ein Kontroll- elemente gedrückt, wird dessen Bedeutung aufgehoben. Stattdessen werden hintere Fenster aktiviert bzw. das vordere nach hinten gestellt (falls BackDrop eingeschaltet ist) * Repeatfunktion für Scrollpfeile unter TOS 1.00 * Probleme mit WM_ARROWED-Nachrichten beseitigt (ARROWFIX-Patches) TOS >= 1.04: Doppelnachricht TOS 2.06/3.06: Doppelnachricht, verzögerte Nachricht, Überlänge TOS 4.01-4.04: Doppelnachricht, verzögerte Nachricht, Überlänge ARROWFIX.GER aus dem ARROWFIX-Paket erläutert Einzelheiten. - Optische Rückmeldung bei der Bedienung von Kontrollelementen [G4] Selektion der Scrollpfeile [G5] Selektion der Scrollbalken [G6] Selektion des Bewegungselements [G7] Selektion des Größenelements * [G2] Rechtsklick auf Fensterrahmen an SCRENMGR (sonst an Applikation) * [G3] Einfacher Linksklick aktiviert Echtzeitfunktionen (sonst Rechtsklick, falls [G2] eingeschaltet ist, sonst Doppelklick) * [L11] Fenster auch links aus Bildschirm schiebbar (sonst nur rechts) GEM-DESKTOP - Bearbeitung hinterer Desktopfenster (Schließen, Scrollen, ...) * BackDrop Integration * Aktivieren und Deaktivieren von Fenstern deselektiert im 2.x/3.x Desktop nicht mehr die Dateien - Das TOS 2.x/3.x Desktop bietet jetzt 8 statt 7 Fenstern, das von TOS 1.x wie bisher 4. * Beim Scrollen in hinteren Fenster wird jetzt versucht soviel wie möglich zu kopieren und nur noch den Rest neu auszugeben. * Einfache Implementierung der Reaktion auf die erweiterten WM_ARROWED-Nachrichten zum Scrollen. Fensterverwaltung: - [G1] Verwaltung von bis zu 40 Fenstern (statt bisher 8) - [L1] Kontrollelemente am Fensterrahmen hinterer Fenster - [L2] Minimierung der Anzahl der Elemente eines Fensterrahmens (bisher hatte ein Fensterrahmen mit einem Größenelement immer sowohl einen horizontalen als auch einen vertikalen Balken) - [G8] Breiterer Rahmen für die Sliderelemente auf dem Fensterrahmen (sehr umstrittene Option :-) * Fensterfarben für TOS 1.x mit WINCOLOR.CPX. Dieses CPX ist aber auch für TOS 2.x/3.x dem Original WCOLORS.CPX vorzuziehen (nach der unmaßgeblichen Meinung des Autors). * Verbessertes Redraw von Fenstern (Neuausgabe von Rahmen und Inhalt) * Aktivieren (und Deaktivieren) verändert nicht mehr das WF_PREVXYWH-Rechteck eines Fensters. In diesem Rechteck wird bei einer Veränderung des Fensters die letzte Position bzw. Größe gespeichert. * [L3] Aktivieren und Öffnen eines Fenster versenden WM_UNTOPPED, Deaktivieren und Schließen eine WM_ONTOP-Nachricht. * Es wird nur noch ein Objektbaum zur Darstellung des Hintergrunds benutzt * wind_set-Modifikationen (optimierte WF_SLIDE Routine; WF_BOTTOM; WF_BEVENT) * wind_get-Modifikationen (WF_NEWDESK; WF_BEVENT; WF_BOTTOM; WF_OWNER; WF_TOP; WF_COLOR; WF_DCOLOR) - Anpassung von wind_calc an den veränderten Rahmenaufbau * Komplett neues Modul zur Berechnung der Rechtecklisten. Optimiert die Berechnungszeit und die Anzahl der Rechtecke. * [L4] Optimiertes Redraw beim Aktivieren eines Fensters: Beim Aktivieren bzw. Schließen eines Fensters werden möglichst nur noch die vorher verdeckten Teile des neuen obersten Fensters ausgegeben. Leider führt dies in einigen Programmen zu unvoll- ständigen Ausgaben. * [L5] Optimiertes Redraw beim Verschieben eines Fensters: Ist diese Schalter eingeschaltet werden alle sichtbaren Teilen des Fensters kopiert und nur für den Rest Redraw-Nachrichten versandt (eventuell müssen die Nachrichten jedoch Verschmolzen werden, dadurch werden auch kopierte Bereiche neu ausgegeben) * [L6] Optimiertes Redraw beim Vergrößern eines Fensters: Es werden nur noch Redraws für die vorher unsichtbaren Bereiche des Fensters versandt * [L7] Optimiertes Verschmelzen von Redraw-Nachrichten: Die bisherigen TOS-Versionen speicherten max. eine Redraw- Nachricht pro Fenster im Nachrichtenpuffer der Applikation. Mußte ein zweite gespeichert werden, wurde das Redraw-Rechteck der ersten durch das umfassende Rechteck beider Nachrichten ersetzt. MultiTOS 1.0 verschmilzt hingegen Redraw-Nachrichten nicht mehr. Beide Lösungen haben Nachteile. Unter WINX ist ein Kompromiß möglich. Redraws werden nur noch verschmolzen, wenn die Gesamtfläche des umfassenden Rechtecks nicht größer als 25% der Summe der Einzelflächen ist. Maximal können zwei Redraws pro Fenster im Nachrichtenpuffer sein. (nur für TOS Versionen > 1.x) * [L9] Die Scrollpfeile eines Fensters können getrennt oder zusammengefaßt in der rechten unteren Ecke des Fensterrahmens dargestellt werden * Es ist jetzt möglich die wind_update()-Kontrolle nur noch zu übernehmen, falls kein anderes Programm die Kontrolle besitzt. Außerdem wird wind_update() auf Unterlauf geprüft. * [G11] Fensterrahmen im 3D-Look (ab GEM 3.31) * [L10] Scrollboxen als Ergänzung der Scrollpfeile * [L12] Fehlerhafte Fensterposition und -groesse korrigieren - Anpassung der anderen Routinen an die größeren Fensterstrukturen Sonstiges: - Vergrößerung des Nachrichtenpuffers einer Applikation von 8 auf 40 Standard-Nachrichten (damit können Verklemmungen des GEM vermieden werden) - Die Mausklickwartezeit wurde fest auf Doppelklick eingestellt. In den bisherigen GEM-Versionen ist die Zeitspanne zwischen dem Mausklick des Anwenders und der Verarbeitung durch den SCRENMGR nicht einheitlich. Konkret hängt die Zeitspanne davon ab, ob mindestens eine Applikation bzw. ein Accessory auf einen Doppel- klick wartet oder nicht. Die Einstellung auf Doppelklick ist notwendig, da sonst, beim Klick auf das Titelelement eines hinteren Fensters, nicht immer zwischen Verschieben und Aktivieren unterschieden werden kann. * Bei der Benutzung des Timers meldet evnt_multi() kein Mausknopf- bzw. Rechteckereignis mehr, solange ein anderes Programm oder der SCRENMGR die Mauskontrolle hat (dies konnte z.B. passieren, während man ein Fenster verschob). * Unterstützung des WF_BEVENT Flags bei der Zuordnung der Button- ereignisse an die Applikationen * TOS 1.x: Die dynamisch angeforderten Strukturen zur Verwaltung von Accessories werden jetzt (wie in den neueren TOS Versionen) explizit gelöscht. Damit wird verhindert, daß es zu Problemen mit AUTO-Ordner Programmen kommt, die den selben Speicher vorher bereits einmal belegt hatten. * [G12] Der Musterbezugspunkt von GEM-Objekten wurde auf die linke obere Ecke des Objekts gesetzt. * Der Name der aktiven Applikation wird jetzt auch in TOS 1.00 und 1.02 vor jedem Aufruf des integrierten Desktops zurückgesetzt. * [L8] Schaltet man diesen Schalter an, meldet WINX Aufrufe von Fensterfunktion mit fehlerhaften Parametern über ein Alert. Diese Option ist vorallem für Entwickler gedacht. * [G13] Beim Starten eines Programms B aus dem laufenden Programm A wird der Name, den GEM der aktiven Applikation zuordnet, auf B gesetzt. Terminiert B wird der Name auf A zurückgesetzt. Damit arbeitet appl_find() jetzt auch im obigen Fall korrekt. (bisher wurde A statt B gefunden). * wind_new ordnet Mausklicks jetzt der Hauptapplikation zu (statt dem SCRENMGR) (TOS >= 2.x/3.x). Damit wird verhindert, daß nach Beendigung eines Programms der erste Klick auf ein Objekt des Desktops verloren geht. * In den Code von wind_new() wurde ein wind_update( BEG_UPDATE) eingefügt. wind_new() wird vom Desktop benutzt um nach der Beendigung von Programmen den Bildschirm aufzuräumen. Durch das Einfügen von wind_update() sind ACCs jetzt besser davor ge- schützt, daß der Aufräumvorgang zu einem ungünstigen Zeitpunkt stattfindet. * Ein Fehler des Taskumschalters von GEM 3.xx wurde gefixt, damit sollte jetzt, während das Alert des CEH (Critical Error Handler) sichtbar ist, kein Taskwechsel mehr stattfinden. * appl_getinfo() INSTALLATION Um all diese Änderungen vornehmen zu können, muß WINX tief in den Programmcode des GEM eingreifen. Der Eingriff kann auf dreierlei Weise erfolgen: a) Patchen einer Kopie des GEM im RAM Man installiert beim Booten des Rechners eine Kopie des GEM im RAM, die dann vor dem Start des GEM durch WINX modifiziert wird. Dies ist mit einem der folgenden Programme möglich: ROMRAM TOS Beschleuniger für TTs; Mailbox Maus HH2 (Freeware); Alexander Herzlinger; >256 KB; PTOS VRAM030 Virtuelle Speicherverwaltung für TT und FALCON030; OverScan, D-12277 Berlin; Alexander Herzlinger; >256 KB; VRAM ROMSPEED TOS Beschleuniger für TTs (Bestandteil von OUTSIDE einer virtuelle Speicherverwaltung für TTs); MAXON Verlag; D-65734 Eschborn; Uwe Seimet; >256 KB; USRS GEMRAM GEM im RAM installieren (ST,TT,FALCON); Mailbox Maus MTK (Freeware); Martin Osieka; 80-200 KB; MOGR (Beschreibung; Bezugsquelle; Autor; Speicherbedarf; Cookie) WINX gehört in diesem Fall nach diesen Programmen in den Ordner \AUTO auf dem Bootlaufwerk und wird somit beim Booten automatisch gestartet. Die Programme werden nur erkannt, wenn sie das entsprechende Cookie im Cookiejar eingetragen haben. b) Patchen einer TOS-Datei Man benutzt WINX um sich eine modifizierte Kopie des TOS zu erstellen, die anschließend auf Eproms gebrannt und in den Rechner eingesetzt wird. Hierzu ruft man WINX vom Desktop auf und erhält dann die Möglichkeit, das TOS aus den ROMs oder einer bereits bestehenden TOS-Datei zu laden. Nachdem WINX das TOS modifiziert hat, kann es abgespeichert werden. c) Patchen einzelner GEM-Routinen Auf Rechnern mit Original-TOS 1.00, 1.02 bzw. 1.04 kann man WINX ohne RAM-Kopie des GEM benutzen. Auch in diesem Fall gehört WINX in den AUTO-Ordner. Beim Start des GEM werden dann nur die von WINX modifizierten Routinen ins RAM kopiert. Diese Methode ist bei späteren TOS-Versionen nicht möglich. Die kopierten GEM-Routinen belegen ca. 16 KByte. Auf Rechnern mit Original-TOS 1.00, 1.02 bzw. 1.04 kann man WINX ohne RAM-Kopie des GEM benutzen. Auch in diesem Fall gehört WINX in den AUTO-Ordner. Beim Start von WINX werden dann nur die Funktionen des GEM ins RAM kopiert, die von WINX modifiziert werden. Diese Methode ist in den neueren TOS- Versionen nicht anwendbar. Die kopierten GEM-Routinen belegen ca. 16 KByte. Zusätzlich zum Speicher für eine Kopie des GEM bzw. der kopierten GEM-Funktionen fordert WINX beim Start des GEM weiteren Speicher für die Fensterstrukturen an (ca. 24 KByte). WINX wurde an die folgenden offiziellen GEM Versionen angepasst: GEM(AES) TOS 1.20 GER 1.00/1.02 1.40 GER 1.04/1.06/1.62 3.00 GER 3.01 3.10 GER/UK 2.05/3.05 3.20 GER/UK 2.06/3.06 3.31 4.01 3.40 4.02-4.04 WINX identifiziert das GEM über die Länge des GEM-TEXT-Segments. GEM Versionen anderer Länder werden bei identischer Länge akzeptiert. KONFIGURATION Die Änderungen, die WINX am GEM vornimmt, können weitgehend über 'Schalter' ein- bzw. ausgeschaltet werden. Die Einstellung der Schalter erfolgt momentan über die Konfigurationsdatei WINX.INF, die sich im AUTO-Ordner befinden muß. Es handelt sich um eine Textdatei, die mit einem Editor verändert werden kann. Ab der WINX-Version 2.1 wird zwischen globalen und lokalen Schaltern unterschieden, wobei die globalen Schalter für alle Applikationen gelten und die lokalen für jede Applikation individuell eingestellt werden können. Alles weitere kann man WINX.INF entnehmen. In Zukunft soll WINX.INF über WINX.CPX manipuliert werden können. Momentan fehlt noch der zündende Funke, wie man das für den Anwender am praktikabelsten aufzieht. Die Wiederholraten von Schließelement, Maximalgröße-Element und Scrollpfeilen können über WINX.CPX eingestellt werden. Benutzt man WINX-modifizierte ROMs, dann braucht man WINXCOOK.PRG im Autoordner um Programme individuell konfigurieren zu können. WINXCOOK lädt beim Start die Konfigurationsdatei WINX.INF, trägt den WINX-Cookie in den Cookie Jar ein und stellt über diesen eine Zugriffsfunktion auf die Konfigurationswerte bereit. Verzichtet man auf WINXCOOK, dann benutzt WINX Defaultwerte. TERMINATE AND KEEP RESIDENT WINX ist ein TKR-Programm und besteht aus einem TKR-Lader in den das TKR-Modul 'WINX.TKR' eingefügt ist. Das TKR-Konzept sieht vor, daß Programme (TKR-Module), die residenten Speicher benötigen, diesen von einem anderen Programm (dem TKR-Lader) bereitgestellt bekommen. Dadurch kann sich das TKR-Modul auf seine eigentliche Aufgabe konzentrieren und belegt nur minimal Speicher. Der hier benutzte TKR-Lader kann beliebig viele TKR-Module und andere Programme enthalten. Ist beim Start des TKR-Laders eine SHIFT- Taste gedrückt, wird für jedes TKR-Modul nachgefragt, ob es gestartet werden soll. Der TKR-Lader gibt bei Programmende die Gesamtgröße des resident gehaltenen Speichers aus. BEKANNTE PROBLEME - Einige ältere Programme verwenden die Fensterkennung zur Indizierung eigener Tabellen, dies führt in der Regel bei vielen offenen Fenstern zum Absturz. - Einige Programme beschränken ohne zwingenden Grund die Anzahl ihrer Fenster (z.B. das Original-Desktop). - WINX Versionen vor 2.0 stürzten ab, wenn Programme die fehler- hafte Fensterkennung -1 (NOWINDOW) benutzten. Dies wird jetzt abgefangen. - TOS14FIX darf nur nach WINX aufgerufen werden. - TEMPLMON Versionen < 2.0 müssen vor WINX aufgerufen werden. - Viele Programme kommen mit der Bearbeitung von hinteren Fenstern nicht zurecht, vorallem das Scrollen in teilweise verdeckten Fenstern bereitet Probleme. - MultiGEM erlaubt nur 10 Fenster pro Applikation. - WINX 2.1 wird erst ab MultiGEM 2.00 (Copyrightjahr 1993!) unterstützt (zum Update siehe Hinweise im MultiGEM Handbuch) - Da MultiGEM in der obigen Version noch die Fensterkennungen auf eigene Werte abbildet, liefern einige neue wind_get()- Modi falsche Kennungen: WF_OWNER, WF_BOTTOM, WF_TOP (für owner und belowwin) - BackDrop funktioniert nur vollständig, wenn es von Programmen unterstützt wird - Einige Graphikkarten (bzw. deren VDI-Treiber) haben offenbar Probleme mit userdefined patterns. In diesem Fall sollte man den Musterbezugspunktschalter auf 0/0 setzen und den Hersteller der Karte bzw. des VDI-Treibers informieren. - Ist der Musterbezugspunkschalter ausgeschaltet, werden Objekte des Fensterrahmens immer komplett ausgegeben. Außerdem kann es dadurch für verschiedene Programme notwendig werden die Redraw- optimierungen auszuschalten (z.B. für XCONTROL). - Hat ein Programm sehr viele Fenster geöffnet (>20) kann es unter Umständen zu Problemen kommen, wenn die Optimierung der Ver- schmelzung der Redraw-Nachrichten eingeschaltet ist [L7] und der Bildschirm komplett neu ausgegeben wird. - Beim Beenden von Applikationen schließt GEM die Fenster von Accessories selbständig. In selten Fällen kann es vorkommen, daß die Accessories nicht rechtzeitig vom GEM über diesen Vorgang informiert werden und sie auf das nicht mehr existente Fenster zugreifen. Ist jetzt die Fehlermeldungsanzeige von WINX eingeschaltet, wird der fehlerhafte Zugriff gemeldet. Dies ist ein konzeptionelles Problem des GEM. Abhilfe: Anzeige ausschalten. - Das Einstellen der Verzögerungswerte funktioniert erst ab TOS 1.04, da das GEM vorher keinen entsprechenden Zähler bereitstellt. - Die Fensterverwaltung des GEMs 3.40 initialisiert den Namen und die Infozeile des Fensters auf Defaultwerte. WINX tut dies nicht. - Durch die Veränderungen im SCRENMGR kann der Anwender Fenster jetzt über den sichtbaren Bereich hinaus vergrößern. Programme, die von einer maximale Fenstergröße ausgehen und diese nicht überprüfen, können daher Probleme bereiten. HINWEISE FÜR ENTWICKLER siehe Datei WINXPROG.GER VEKTOREN, COOKIES, ENVIRONMENT, ... Im Fall c) wird der LineF-Vektor verbogen (XBRA-Kennung AESF). WINX (bzw. WINXCOOK, das Zusatzprogramm für ein WINX modifiziertes ROM) erzeugt ab der Version 2.1 den Cookiejareintrag 'WINX'. Dieser Cookie enthält als Wert eine Zeiger auf einen Funktion über die bestimmte Eigenschaften der akt. WINX-Version erfragt werden können. Ist der WINX-Cookie installiert, wird beim Start des GEM der GEMDOS-Vektor verbogen (XBRA-Kennung WINX). GEMRAM bestimmt die Ausgabesprache zunächst aus den OSHEADER, dann über den _AKP-Cookie (falls er existiert). Beim Start aus dem Desktop wird zusätzlich die Environmentvariable "AE_LANG" ausgewertet. Falls als Sprache etwas anderes als Deutsch ermittelt wird, benutzt GEMRAM Englisch. Das Datumsformat wird aus dem _IDT-Cookie bestimmt, falls dieser nicht existiert über die Ausgabesprache. COPYRIGHT Autor: (\/) Martin Osieka Anschrift: Martin Osieka, Erbacherstr. 2, D-64283 Darmstadt, Bundesrepublik Deutschland Internet: Martin_Osieka@mtk.maus.de Schriftlichen Anfragen bitte immer einen frankierten und adressierten Rückumschlag beilegen. Das Programm WINX.PRG darf auf beliebige Art und Weise weiter- verbreitet werden, solange alle Dateien des Programmpakets beiliegen. Zum Paket gehören: WINX.PRG, WINX.CPX Patchprogramm und Konfigurationsmodul WINXCOOK.PRG Zusatzprogramm für WINX im ROM WINX.INF Datei mit Konfigurationsinformationen WINX.GER, WINXPROG.GER Dokumentation (deutsch) WINX.ENG, WINXPROG.ENG Dokumentation (englisch) WINX.UPL Upload-Beschreibung (deutsch) Die Benutzung des Programms erfolgt auf eigene Gefahr. SIEHE AUCH Dokumentation von GEMRAM, ARROWFIX und WINCOLOR